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Abstract: Stochastic Petri nets are commonly used for modeling distributed systems in order 

to study their performance and dependability. This paper proposes a realization of stochastic Petri 
nets in SystemC for modeling large embedded control systems. Then statistical model checking 
is used to analyze the dependability of the constructed model. Our verification framework allows 
users to express a wide range of useful properties to be verified which is illustrated through a case 
study. 
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Dependability Analysis of Control Systems using SystemC 
and Statistical Model Checking 

Resume : Petri nets stochastiques sent couramment utilises pour la modelisation de systemes 
distribues afin d’etudier leur performance et fiabilite. Get article propose une realisation de Petri 
nets stochastiques en SystemC pour la modelisation de grands systemes de controle embarques. 
Puis statistical model checking est utilise pour analyser la fiabilite du modele construit. Notre 
cadre de verification permet aux utilisateurs d’exprimer une large gamme de proprietes utiles a 
verifier qui est illustree par une case-study. 

Mots-cles : SystemC, Statistical Model Checking, Formal Verification, Dependability Analysis, 
Petri Nets 
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1 Introduction 


Computer-based control systems are increasingly used now in a wide range of industrial and 
military domains such as manufacturing, transport, energy and defense. In many cases, they 
are safety-critical systems (e.g., control systems for air-trafhc, power plants, medical devices). 
Hence, it is necessary to quantify the probability or rate of all safety-related faults: How likely 
the system is available to meet a demand for service? What is the probability that the system 
repairs itself after a failure (e.g., the system conforms to existent and prominent standards such 
as the Safety Integrity Levels)? A general approach for performing such dependability analysis 
consists in constructing and analyzing a state-based model of the system [20, 8]. One of the 
main approaches. Probabilistic Model Checking (PMC), is an automatic technique for checking 
whether or not probabilistic models satisfy certain specifications, which is widely used to verify 
timed and probabilistic systems [11, 16[. One of the main challenges is the complexity of the 
algorithms in terms of execution time and memory space. Indeed, such algorithms suffer from 
the state space explosion problem, that is, the size of the state space tends to grow exponentially 
faster than the size of the system. As a result, the analysis of large systems is infeasible. 

An alternative way to evaluate these systems is Statistical Model Checking (SMC), a simulation- 
based approach. Simulation-based approaches do not construct all the reachable states of the 
system-under-verification (SUV), thus they require far less execution time and memory space 
than numerical approaches. They have shown the advantages over other methods such as PMC 
on several case studies [15, 10[. 

In this work, we construct a SMC-based verification framework to analyze dependability 
of large industrial embedded control systems. Stochastic high-level Petri nets (SHLPNs) are 
traditionally used for modeling distributed control systems in order to study their performance 
and dependability. Therefore, we propose an approach to model the system dependability by 
realizing SHLPNs in SystemC. 

We then analyze the constructed model in SystemC with Plasma Lab [2[, a statistical model 
checker for stochastic processes, in which the properties to be verified are expressed in Bounded 
Linear Temporal Logic (BLTL). The implementation contains two main components: a monitor 
generator that instruments the SystemC model to generate the set of execution traces, and a 
checker that verifies the satisfaction of the properties based on the given set of execution traces. 
The monitor generation relies on the techniques proposed by Tabakov et al. [29[ that provide a 
rich set of primitives for exposing different parts of the model state during a SystemC simulation. 

The remainder of this paper is organized as follows: the next section introduces the SystemC 
modeling language and reviews the main features of SMC. We consider the execution traces of a 
SystemC model and the implementation of our verification framework in Section 3 and Section 
4. An approach to model the dependability of computer-based control systems is proposed in 
Section 5. Section 6 illustrates the modeling approach and the verification procedure by a case 
study. The paper terminates with some related work, a conclusion and an outlook to some 
directions for future research. 


2 Background 


This section introduces the SystemC modeling language and reviews the main features of statis¬ 
tical model checking for stochastic processes. 
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2.1 The SystemC Language 

SystemC^ is a CH—h library [9] providing primitives for modeling hardware and software systems 
at the level of transactions. Every SystemC model can be compiled with a standard C++ 
compiler to produce an executable program called executable specification. This specification is 
used to simulate the system behavior with the provided event-driven simulator. 

2.1.1 Language Features 

A SystemC model is hierarchical composition of modules {sc_module). Modules are building 
blocks of SystemC design, they are like modules in Verilog [30], classes in C++. A module 
consists of an interface for communicating with other modules and a set of processes running 
concurrently to describe the functionality of the module. An interface contains ports {sc_port), 
they are similar to the hardware pins. Modules are interconnected using either primitive channels 
(i.e., the signals, sc_ signal) or hierarchical channels via their ports. Channels are data containers 
that generate events in the simulation kernel whenever the contained data changes. 

Processes are not hierarchical, so no process can call another process directly. A process is 
either a thread or a method. A thread process (sc_ thread) can suspend its execution by calling 
the library statement wait or any of its variants. When the execution is resumed, it will continue 
from that point. Threads run only once during the execution of the program an are not expected 
to terminate. On the other hand, a method process (sc_ method) cannot suspend its execution 
by calling wait and is expected to terminate. Thus, it only returns the control to the kernel when 
reaching the end of its body. 

An event is an instance of the SystemC event class (sc_ event) whose occurrence triggers or 
resumes the execution of a process. All processes which are suspended by waiting for an event 
are resumed when this event occurs, we say that the event is notified. A module’s process can 
be sensitive to a list of events. For example, a process may suspend itself and wait for a value 
change of a specific signal. Then, only this event occurrence can resume the execution of the 
process. In general, a process can wait for an event, a combination of events, or for an amount 
time to be resumed. 

2.1.2 SystemC Simulation 

In SystemC, integer values are used as discrete time model. The smallest quantum of time 
that can be represented is called time resolution meaning that any time value smaller than the 
time resolution will be rounded off. The available time resolutions are femtosecond, picosecond, 
nanosecond, microsecond, millisecond, and second. SystemC provides functions to set time 
resolution and declare a time object, for example, the following statements set the time resolution 
to 10 picosecond and create a time object tl representing 20 picoseconds. 

1 I sc_set_time_reSOlution (10 , SC_PS) ; 

2 |sc_time tl(20, SC_PS); // SC_PS : picosecond 

The SystemC simulator is an event-driven simulation [1, 22]. It establishes a hierarchical 
network of finite number of parallel communicating processes which under the supervision of the 
distinguished simulation kernel process. Only one process is dispatched by the scheduler to run 
at a time point, and the scheduler is non-preemptive, that is, the running process returns control 
to the kernel only when it finishes executing or explicitly suspends itself by calling wait. Like 
hardware modeling languages, the SystemC scheduler supports the notion of delta-cycles ]19]. 
A delta-cycle lasts for an infinitesimal amount of time and is used to impose a partial order 
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of simultaneous actions which interprets zero-delay semantics. Thus, the simulation time is not 
advanced when the scheduler processes a delta-cycle. During a delta-cycle, the scheduler executes 
actions in two phases: the evaluate and the update phases. 

The simulation semantics of the SystemC scheduler is presented as follows: (1) Initial¬ 
ize. During the initialization, each process is executed once unless it is turned off by calling 
dont_initialize(), or until a synchronization point (i.e., a wait) is reached. The order in which 
these processes are executed is unspecified; (2) Evaluate. The kernel starts a delta-cycle and run 
all processes that are ready to run one at a time. In this same phase a process can be made 
ready to run by an event notification; (3) Update. Execute any pending calls to update() re¬ 
sulting from calls to request_update() in the evaluate phase. Note that a primitive channel uses 
request_update() to have the kernel call its updatef) function after the execution of processes; 
(4) Delta-cycle notification. The kernel enters the delta notification phase where notified events 
trigger their dependent processes. Note that immediate notifications may make new processes 
runable during step (2). If so the kernel loops back to step (2) and starts another evaluation 
phase and a new delta-cycle. It does not advance simulation time; (5) Simulation-cycle notifica¬ 
tion. If there are no more runnable processes, the kernel advances simulation time to the earliest 
pending timed notification. All processes sensitive to this event are triggered and the kernel 
loops back to step (2) and starts a new delta-cycle. This process is finished when all processes 
have terminated or the specified simulation time is passed. The simulation semantics can be 
represented by the pseudo code in Listing 1. 
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PC // All primitive channels 
P // All processes 

R = 0 // Set of runnable processes 

D = 0 // Set of pending delta notifications 

U = 0 // Set of update requests 

T = 0 // Set of pending timed notifications 

// Start elaboration: collect all update requests in U 
for all chan G U do 
run chan.update() 
end for 

for all p G P do 

if p is initialized and p is not clocked thread then 
R = R U p // Make p runnable 
end if 
end for 

for all p G P do 

if p is triggered by an event in D then 
R = R U p 
end if 

end for // End of initialization phase 
repeat 

while R ^ 0 do // New delta-cycle begins 
for all r G R do // Evaluation phase 
R = R \ r 

run r until it calls wait or returns 
end for 

for all chan G U do // Update phase 
run chan.update() 
end for 

for all p G P dp // Delta notification phase 
if p is triggered by an event in D then 
R = R U p // Make p runnable 
end if 

end for // End of delta-cycle 
end while 

if T 0 then 

Advance the simulation clock to the earliest timed delay t 
T = T \ t 

for all p G P do // Timed notification phase 
if t triggers p then 

R = R U p // Make p runnable 
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46 

47 

Listing 1: Simulation semantics of SystemC 


end if 
end for 
end if 

until end of simulation 


2.2 Statistical Model Checking 

Let At be a model of a stochastic process and ip he & property expressed as a BLTL formula. 
BLTL is a temporal logic with bounded temporal operators, ensuring that the satisfaction of a 
formula by a trace can be decided in a finite number of steps. The statistical probabilistic model 
checking problem consists in answering the following questions. 

• Qualitative. Is the probability that M satisfies p greater or equal to a threshold 9 with a 
specific level of statistical confidence? 

• Quantitative. What is the probability that A1 satisfies p with a specific level of statistical 
confidence? 

They are denoted by M |= Pr{p) and M. |= Pr>g(</?), respectively. 

The key idea of SMC [18] is to get, through simulation, a large amount of independent 
execution traces and count the number of traces that satisfy p. The ratio of this number over 
the total number of execution traces provides the probability that the property holds. Then 
statistical results associate a level of confidence to this probability, depending on the number of 
execution traces. Many statistical methods including sequential hypothesis testing, Monte Carlo 
method, or 2-sided Chernoff bound are implemented in a set of existing tools [32, 2[, that have 
shown their advantages over other methods such as PMC on several case studies. 

Although SMC can only provide approximate results with a user-specified level of statistical 
confidence (as opposed to the exact results provided by standard probabilistic model checking 
method), it is compensated for by its better scalability and resource consumption. Since the 
models to be analyzed are often approximately known, an approximate result in the analysis of 
desired properties within specific bounds is quite acceptable. SMC has recently been applied in a 
wide range of research areas including software engineering (e.g., verification of critical embedded 
systems) [10[, system biology, or medical area [15[. 


3 SMC for SystemC Models 

This section illustrates the use of SMC for verifying a SystemC program exhibiting timed and 
probabilistic characteristics by showing that the operational semantics of the program is viewed as 
a stochastic process. The implementation of our SMC-based verification framework is considered 
as well. 

3.1 SystemC Model State 

Temporal logic formulas are interpreted over execution traces and traditionally a trace has been 
defined as a sequence of states in the execution of the model. Therefore before we can define 
an execution trace we need a precise definition of the state of a SystemC simulation. We are 
inspired by the definition of system state in [29[, which consists of the state of the simulation 
kernel and the state of the SystemC model. We consider the external libraries as black boxes, 
meaning that their states are not exposed. 


RR n° 8762 




Ngo & Legay 


The state of the kernel contains the information about the current phase of the simulation 
and the SystemC events notified during the execution of the model. We denote the finite set of 
variables whose value domain represent the information about the current phase of the kernel by 
Vker, and the finite set of variables whose value domain represent the event notification by Veve- 

The state of the SystemC model is the full state of the C++ code of all processes in the model, 
which includes the values of the variables, the location of the program counter, the call stack, and 
the status of the processes. We use Vyar, Vioc, Vsta, and Vproc to denote the finite sets of variables 
whose value domains represent the values of the variables, the location of the program counter, 
the call stack and the status of the processes, respectively. Let V = {uq, ...,u„_i} = IJ^, 14 with 
k € {ker,eve,var,loc, sta,proc}, be a finite set of variables that takes values in a domain Dx. 
A value in Dx represents a state of a SystemC simulation. 

We consider here some examples of variables in V that represent the state of the simulation 
kernel and the SystemC model. A system state can consists of the information about all locations 
before the execution of all statements that contain the devision operator “/” followed by zero or 
more spaces and the variable “a” in a SystemC model (e.g., the statement y = (x + 1) / a). 
Let Producer and Consumer be two modules of a SystemC model. Assume that Producer has a 
function send() and Consumer has a function receive(). Two variables send_start and send_done 
can be defined as Boolean variables in V that hold the value true immediately before and after 
a call of the function send(), respectively to express the status of the call stack. Similarly, the 
variable rev holds the value true immediately after a call of the function receive (). Assume again 
that Producer has an event named write_ event, to observe whenever this event is notified, we 
can use a variable we_ notified that holds the value true immediately when the event is notified. 
We will consider how these variables can be defined in our implementation of the verification 
framework in the next section. 

We have discussed so far the state of a SystemC model execution. It remains to discuss how 
the semantics of the temporal operators is interpreted over the states in the execution of the 
model. That means how the states are sampled. The following definition gives the concept of 
temporal resolution, in which the states are evaluated only in instances in which the temporal 
resolution holds. It allows the user to set granularity of time. 

Temporal resolution A temporal resolution % is a finite set of Boolean expressions defined 
over V which specifies when the set of variables V is evaluated. 

Temporal resolution can be used to define a more fine-grained model of time than a coarse¬ 
grained one provided by a cycle-based simulation. We call the expressions in 7^ temporal events. 
Whenever a temporal event is satisfied or the temporal event occurs, V is sampled. For example, 
assume that we want the set of variables to be sampled whenever at the end of simulation-cycle 
notification or immediately after the event write_ event is notified during a run of the model. 
Hence, we can define a temporal resolution as the following set %• = {edciWe_notified'\, where 
Cdc and we_ notified are Boolean expressions that have the value true whenever the kernel phase 
is at the end of the simulation-cycle notification and the event write_ event notified, respectively. 

We denote the set of occurrences of temporal events from %■ along an execution of a SystemC 
model by Tf, called a temporal resolution set. The value of a variable u € C at an event 
occurrence Cc € Tf is defined by a mapping : Tf —)■ D„. Hence, the state of the SystemC 
model at Cc is defined by a tuple 

A mapping : Tf T is called a time event that identifies the simulation time at each oc¬ 
currence of an event from the temporal resolution. Hence, the set of time points which correspond 
to a temporal resolution set Tf = {cco ecjv_i}, N G N is given as follows. 

Time tag Given a temporal resolution set Tf, the time tag T corresponding to Tf is a finite 
or infinite set of non-negative reals {to,ti, ...,fx-i}, where — U = dti G IR>o,ti = 
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3.2 Model and Execution Trace 

A SystemC model can be viewed as a hierarchical network of parallel communicating processes. 
Hence the execution of a SystemC model is an alternation of the control between the model’s 
processes, the external libraries and the kernel process. The execution of the processes is super¬ 
vised by the kernel process to concurrently update new values for the signals and variables w.r.t 
the cycle-based simulation. For example, given a set of runnable processes in a simulation-cycle, 
the kernel chooses one of them to execute first in a non-deterministic manner as described in the 
prior section. 

Let V be the set of variables whose values represent the state of a SystemC model simulation. 
Our way to mix stochastic and non-deterministic characteristics consisting of assuming that, at 
any moment of time, the values variables in P C V are determined by a given probability 
distribution (i.e., from the probability distributions used in the model). The values of variables 
in y \ P are chosen in the non-deterministic manner of the simulation scheduler. At any given 
moment of time, it is allowed that the choice of the variables in y \ P might influence the 
distribution on the next values of variables in P. 

Given a temporal resolution % and its corresponding temporal resolution set along an ex¬ 
ecution of the model Tf = {scq, ■■., ec„_i}, iV G N, the evaluation of V at the event occur¬ 
rence Cc, is defined by the tuple ^ state of the model, denoted by y(ecj = 

(y(ecJ(uo),y(ecJ(ui),...,y(ecJ(u„_i)), where y(ecj(ufc) = Chie-a) with k = 0,...,n-l is the 
value of the variable Vk at Cc, . We denote the set of all possible evaluations by V-ps C Dy, called 
the state space of the random variables in V . State changes are observed only at the moments 
of event occurrences. Hence, the operational semantics of a SystemC model is represented by 
a stochastic process {(y(ecj,^t(ecj))Cc; G 77*}igN) taking values in V-ps x K>o and indexed by 
the parameter , which are event occurrences in the temporal resolution set Tf. An execution 
trace is a realization of the stochastic process is given as follows. 

Execution trace An execution trace of a SystemC model corresponding to a temporal res¬ 
olution set Tf = {bco, ..., ec„_i}, iV S N is a sequence of states and event occurrence times, 
denoted by w = (sq; ^o)(si; tAf-i), such that for each i G 0, ...,N — 1, Si = V(ecJ and 

ti = ) ■ 

N is the length of the execution, also denoted by |a;|. We denote the prefix of oj hy ojk = 
{so, to), {si,ti)...{sk,tk), and the sufhx by = {sk,tk)isk+i,tk+i)--{sN-i,tN-i)- 

Let y' C y, the projection of uj on V, denoted by w fy', is an execution trace such that 
Iw iv' I = |w| and Vu S V, Vcc S Tf, V'{ec){v) = V{ec){v). 

3.3 Expressing Properties 

We recall the syntax and semantics of BLTL [28], an extension of Linear Temporal Logic (LTL) 
with time bounds on temporal operators. A BLTL formula ip is defined over a set of atomic 
propositions AP as in LTL. A BLTL formula is defined by the grammar ip ::= true\false\p G 
AP\ipi A ip 2 \~^'p\'pi U<T ip 2 , where the time bound T is an amount of time or a number of states 
in the execution trace. The temporal modalities F (the “eventually”, sometimes in the future) 
and G (the “always”, from now on forever) can be derived from the “until” U as follows. 

P<r ip = true Upp ip and Gpp ip = -^F<t -^ip 

The semantics of BLTL is defined w.r.t execution traces of the model Ai. Let uj be an execution 
trace of Ai, we denote hy oj \= ip that fact that oj satisfies the BLTL formula ip. 

• ixj^ \= true and uj^ \f=- false 
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• U!^ 1= p,p € AP iff p G L{sk), where L{sk) is the set of atomic propositions which are true 
in state 

• uj^ \= px f\ ip 2 iff \= Pi and uj^ ^ p 2 

• \= -np iff ^ 

• \= Pi U<T P 2 iff there exists an integer i such that \= p 2 , So<j<i(ffc+j —tk+j-i) < 

T, and for each 0 < j < \= pi 

In our framework, the set of atomic proposition AP consists of the predicates defined over the set 
of variables V. Using these predicates, users can define temporal properties related to the state 
of the kernel and the state of the SystemC model. Recall that Producer and Consumer are two 
SystemC modules that have two functions send() and receive(), respectively. We consider the 
following variables send_start, send_done and rev € V. They expose the state of the SystemC 
model as described in the section above. Assume that we want to express the property “over a 
period ofTi time units, send() remains blocked until receive() has returned within T 2 time units”. 
This property can be specified with the “until” operator that is given as follows. 

G<Ti{send_start —?> {^send_done U<t 2 rev)) 


4 Implementation 

We have implemented a SMC-based verification framework [26] which is used to analyze the 
case study in Section 6. Our implementation contains two main components: a monitor and 
aspect-advice generator (MAG) and a statistical model checker (SystemC Plugin). The flow of 
our framework is depicted in Fig. 1. 



Figure 1: The framework’s flow 


4.1 Monitor and Aspect-Advice Generator 

In principle, the full state can be observed during the simulation of the model. In practice, 
however, users define a set of variables of interest, called observed variables, and only these 
variables appear in the states of an execution trace. Given a SystemC model, an observed 
variable is a variable of primitive type (e.g, usual scalar or enumerated type in C/CH—h). The 
value of this variable represents a part of the full state of the model. We use Vots C U to 
denote the set of observed variables. Then, the observed execution traces of the model are 
the projections of the execution traces on Vobs, meaning that for every execution trace w, the 
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corresponding observed execution trace is w ivob,- In the following, when we mention about 
execution traces, we mean observed execution traces. 

The implementation of MAG allows users to define a set of observed variables that is used 
with a temporal resolution to generate a monitor based on the techniques in [29] in order to make 
an instrumented SystemC model. The instrumented model will produce a set of execution traces 
of the model. The generated monitor evaluates the set of observed variables at every time point 
in which an event of the temporal resolution occurs during the SystemC model simulation. The 
generator also generates an aspect-advice file that is used by AspectC++ [6] to automatically 
instrument the SystemC model. 

4.2 SystemC Plasma Lab Plugin 

Our statistical model checker is implemented as a plugin of Plasma Lab [2] which establishes 
an interface between Plasma Lab and the instrumented model being executed by the simulator. 
In the current version, the communication is done via the standard input and output. The 
plugin requests new states until the satisfaction of the formula to be verified can be decided, 
which terminates because the temporal operators are bounded. Similarly, depending on the 
hypothesis testing algorithms (e.g., sequential hypothesis testing, Monte Carlo simulation, or 
2-sided Chernoff bound), the plugin will request new traces from the instrumented model. 

4.3 Running Verification 

Running the verification framework consists of two steps as follows. First, users define a set of 
observed variables and a temporal resolution in a configuration file, as well as other necessary 
information. From that information, the generator generates the monitors and aspect-advices 
that are used by AspectC"*"^ to produce the instrumented SystemC model. In addition, the gen¬ 
erator can automatically generate a Plasma Lab project file according to the desired properties. 
The instrumented model and the generated monitors are compiled together and linked with the 
SystemC simulation kernel into an executable model in order to make a set of execution traces of 
the system. In the second step, the plugin of Plasma Lab is used to verify the desired properties. 
The satisfaction checking of the properties is brought out based on the set of execution traces by 
executing the instrumented SystemC model and can be done by several hypothesis testing algo¬ 
rithms provided by Plasma Lab. The full implementation of our verification framework including 
the monitor and aspect-advice generator and the checker can be downloaded on the website of 
Plasma Lab^. 

5 Modeling Dependability in SystemC 

SHLPNs are high-level Petri nets (HLPNs) [24, 14, 21[, in which each transition execution has 
a duration described by an exponential distribution. They are commonly used for modeling 
distributed systems in order to study their performance and dependability [8, 21, 20[. In this 
section, we propose an approach for realizing SHLPNs in SystemC such that the semantics is 
preserved. 

5.1 Stochastic High-Level Petri Nets 

High-level Petri nets provide a compact representation of complex systems. There are many 
different types of HLPNs that have been proposed in literature such as predicate transition 

^MAG manual: https://project. inria.fr/plasma-lab/docuinentatioii/tutorial/mag_manual/ 
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nets [7], coloured Petri nets [12] and relation nets [27]. However, in [13, 27] it is proved that 
one can translate the HLPN of a system in one type into any other type. Due to the intuition 
and the modeling elegance we consider the predicate transition nets in which the tokens are 
coloured or typed tokens [14] . Each place is annotated with a data type. Each place is associated 
with a place capacity K which bounds for the number of tokens that the place can contain. 
The arcs are labeled by tuples of token variables. The zero-tuple indicates an ordinary place, 
meaning a no-argument token. The transitions are annotated with guard formulas defined over 
variables labelling the adjacent arcs and a set of variable assignments. A transition is enabled, 
that is may execute or fire, whenever 1 ) all input places carry enough tokens, 2 ) there is an 
assignment of tokens to token variables that satisfies the guard formula of the transition, and 
3) each output place capacity is sufficient to store the tokens produced by the transition. By 
firing, a transition removes and adds tokens from/to places according to the expressions labeling 
the arcs. SHLPNs are high-level Petri nets in which each execution of a transition lasts for a 
given amount of time, called firing time. Firing times are specified by an exponential distribution 
associated to each transition. Due to the memoryless property of the exponential distribution, 
this class of SHLPNs is isomorphic to continuous-time Markov chains (CTMCs) as shown in [21] . 
We consider the example in Fig. 2. This net is a part of the SHLPN of our case study models the 



Figure 2: Stochastic high-level Petri net example 

reliability of the input processor. The example consists of 51 I/O places with data type int {pi 
to P 50 represent the number of functional sensors in each group and p^i representing the current 
status of the processor) and output place p ^2 with data type bool carries a token with the value 
true whenever the processor reboots successfully. Their capacities are 1. Each of transitions 
ti,t 2 and fa is annotated with a firing time following the exponential distribution with the rate 
Xi,i = 1, ...,3. These rates may be marking-dependent. With the marking depicted in Fig. 2, 
Si to S 50 , and i are assigned values 3 and 2 respectively, both transitions ti and t 2 are enabled 
to fire that means they conflict, where s = Cfe = 1 if s^ > 2 , otherwise ak = 0. Assume 

that ti fires, pi to pso carry the same previous token values, psi caries the value 0 and P 52 is 
empty. 

5.2 Connection between HLPNs and Rule-Based Systems 

A rule-based system (or production based system) [3] consists of a working memory containing 
known facts, a production memory containing rules, and an inference engine which matches the 
rules with the working memory to infer new facts by applying the selected rule among all the 
applicable rules and the existing facts. The rules syntactically are of the form “if conditions then 
actions”. The conditions are patterns that are checked for the rule activation, called the rule 
antecedent. If the conditions match with the facts, the actions, called the rule consequent, are 
performed. Fig. 3 depicts the main structure of a forward chaining inference algorithm. The 
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void Infer(working_mGmory, 


2 


production_memory) { 
rules = Select(working_memory, 


1 rule_set Select(working_memory, 



7 

8 


6 


3 


4 


5 


production_memory); 
} //END while 

} 


production_memory) ; 
while(rules ^0) { 
rule = SolveConf1icts(rules); 
ApplyRule(rule); 
rules = Select(working_memory 


2 rules = 0; 

3 for rule G production_memory { 

4 if Match(rule,working_memory) 

5 rules = rules U rule; 

6 } //END for 

7 return rules; 

8 > 


Figure 3: A forward chaining inference algorithm 


main function, Infer, executes the rule system until no more rule can be executed. The function 
Select identifies a set of rules that matches the facts in the working memory, according to the 
Match function, which maps the variables appearing into the conditions to some constants from 
the facts of the working memory. The function Solve Conflicts selects one of the selected rule 
to be fired. Finally, the function ApplyRule executes the rule actions and updates the working 
memory. 

For every HLPN one can construct a rule-based system, as shown in [31, 4]. The transforma¬ 
tion consists of the production memory and working memory constructions. For each transition 
of the net, a rule is added in which the conditions and actions are defined by the guard formula, 
the set of variable assignments, the input and output places of the transition. For each input 
place, the facts that bound the tokens to the variables labeling the arc connecting the place 
to the transitions are added and the condition expressing that the place carries enough copies 
of proper tokens, as well as the action of removing tokens from the place are defined for the 
corresponding rule. For each output place, the action of adding tokens to the place is associated, 
by specifying the place name and the variables on the arc connecting the transition to the place 
and the condition expressing that the place’s capacity is not exceeded by adding the produced 
tokens is defined. The actions of adding and removing tokens update the facts in the working 
memory. The initial working memory is constructed based on the initial marking of the net. In 
other words, a fact represents a multiset of constants. This set is compatible with the type and 
capacity of its associated place. The following proposition from [31, 4[ shows that the HLPN 
and its corresponding transformed rule-based system are semantically equivalent. 

Proposition 5.1 For every high-level Petri net, a rule-based system exists that is semantic 
equivalent. 

The proof of Proposition 5.1 and the similarities between HLPNs and rule-based systems have 
been studied in [31, 4, 25[ by showing that the rules applied by the inference algorithm represent 
the reachability set from the initial marking of the initial Petri net. It follows that the inference 
algorithms can be use to implement the operational semantics of the stochastic high-level Petri 
nets. In addition, it is shown in [31, 4[ that the implementation of HLPNs semantics based 
on rule-based systems with an improved version of the inference algorithm was described by 
Forgy [5[ , is most efficient when the net have large number of places and large number of tokens 
distributed among the places, as well as when the large number bounded variables labeling the 
arcs. In the next section, we propose an approach to realize SHLPNs by implementing the 
inference algorithms in SystemC. 


5.3 Realization of SHLPNs 


We illustrate our realization of the inference algorithm in Fig. 3 with the example in Fig. 2. 
It is implemented by a SystemC module as shown in Fig. 4, in which the Infer function is a 
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thread process in SystemC. The initialization initialize the working memory by setting all places, 
the capacity and the initial marking in the constructor method (lines 37 to 40). And a place 
is implemented as an instance of a template class (i.e., place<int>) that contains the facts. 
The template class has the methods for getting a token value (get), storing a token (mark), 
removing a token (demark), getting the capacity (get_ capacity), and the current number of 
tokens (get_ num) in a place. 

Consider a SHLPN with the current marking Mj, transitions become enabled as usual, i.e., 
if all input places have sufficiently tokens and the guard formulas are satisfied. However, there 
is a time, which has to elapse, before an enabled transition fires. We denote the set of all 
enabled transitions ti, ..., t^ in Mj by E(Mj). Since all firing times are independent exponentially 
distributed, the minimum firing time is also exponentially distributed with the rate A = 
and the probability that a given enabled transition, say tk, samples the minimum firing time 
Pr(tk\Mj) = Xk/'^i-.tieE{Mj)\- 
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SC_M0DULE (Shlpn) { 

SC_HAS_PR0CESS (Shlpn) ; 
public : 

Shlpn(sc.module.name name, gsl_rng 
//operation of the net 
void Inf er() ; 
private : 

place<int> p[51]; 
place<bool> p52; 
int i , s [50] ; 
bool r ; 

//firing rates 

double rl , r2 , r3 , sum_r , ft ; 

//GSL random generator 
gsl_rng ♦rnd; 

//enabled transitions 
bool e [3] ; 

//return enabled transitions 

int Select () ; 

int SolveConflicts () ; 

ApplyRule( int rule); 

>; 

void Shlpn::Infer () { 
for (int k = 0; k < 3; k++) 
e[k] = false ; 
sum_r = ft = 0; 
int rules = SelectO; 
whileCrules > 0) { 
int rule = SoIveConf1icts () ; 
ApplyRule(rule); 
for (int k = 0; k < 3; k++) 
e [k] = false ; 
sum_r = ft = 0; 
rules = Select () ; 

} //END while 


37 

j N 38 
*rnd); 
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48 
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55 

56 
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58 

59 
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61 
62 

63 

64 

65 

66 

67 

68 

69 

70 


Shlpn::Shlpn(sc_module_name name, gsl_rng 
♦rnd) { 

//initialization 
SC_THREAD(Infer) : 

} 

int Shlpn::SolveConflicts() { 
int rule; 

double prl, pr2, pr3; 

//probability tl fires 
prl = e [0] ? rl/sum_r ; 0; 

//probabilities of t2, t3 
pr2 = e [1] ? r2/sum_r : 0; 
pr3 = e [2] ? r3/sum_r : 0; 

//fired transition 

rule = gsl_discrete({prl,pr2,pr3},rnd); 

} 

void Shlpn::ApplyRule( int rule) { 
switch (rule) { 
case 0: //fire tl 
//elapse firing time 
ft = gsl_exp(sum_r,rnd); 
wait (ft,time_unit); 
for (int k = 0; k < 51; k++) 
p[k] .demark () ; 
i = 0; 

for (int k = 0; k < 50; k + + ) 
p[k] .mark(3) ; 
p[50] .mark(i) ; 
break ; 

case 1: //fire t2 
case 2: //fire t3 
default : 
break ; 

}// END switch 

> 


Figure 4: SystemC code for example in Figure 2 

Therefore, the implementations of the functions SolveConflicts and ApplyRule is done as 
follows. Given a set of all enabled rules from the function Select in Appendix A, SolveConflicts 
(lines 41 to 51) determines a rule to be applied from the set of selected rules using a discrete 
distribution over Pr(tk\Mj) (lines 45 to 50). The firing time before the firing of selected rule in 
ApplyRule (lines 52 to 70), is sampled from the exponential distribution with the rate A (lines 56 
to 57). We employ the implementation of the discrete and exponential distributions from GNU 
Scientific Library (GSL). The firing time elapsing is simulated by a wait() statement with an 
amount of time equals to the firing time (i.e., measured by the time unit in the simulator). 

The implementation of the function Select and the place template class are given in Listing 
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2 and Listing 3. 
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int Shlpn::Select () { 
int s, rules = 0; 
bool check_p = true; 

//check tl is enabled 

//check all input places have sufficiently tokens 
forCint k = 0; k < 50; k + + ) ■( 

if (p [k]->get_num() > 0) 

s[k] = p[k]->get () ; 

else { 

check_p = false; 
break ; 

} 

} //END for 

if (p [50]->get_num() > 0) 
i = p [50] ->get () ; 
else check_p = false; 

//check the guard formula 
if (check_p) { 

for (int k = 0; k < 50; k++) 
if (s [k] >= 2) 

s = s + 1; 

if (s >= 37 && i > 0) ■[ 

//set tl is enabled transition 

e[0] = true ; 

sum_r = sum_r + rl ; 

rules = rules + 1; 

> //END if 
} //END if 

//check t2 is enabled 
//check t3 is enabled 
return rules; 

> 


Listing 2: SystemC code for the Select function 
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template <class type> class place { 
public : 

type get(int); //get token at index 
bool mark(type); //store token 
void demark(int); //delete token at index 
int get_capacity () ; //place capacity 
int get_num(); //number of tokens 


template <class type> type place<type>;:get( int index) { 
//code 

> 

template <class type> bool place<type>;:mark(type t) { 
//code 

> 


Listing 3: SystemC code for a place 


6 Case Study and Results 

In this section, our SystemC-realization is used to model the dependability of a large embedded 
control system. We also demonstrate the use of our verification framework to analyze the resulting 
model. The number of components in our system makes numerical approaches such as PMC 
unfeasible. 
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6.1 An Embedded Control System 

The case study is closely based on the one presented in [23, 17] but contains much more compo¬ 
nents. The system, depicted in Fig. 5, consists of an input processor (/) connected to 50 groups 
of 3 sensors (from to ^so), an output processor (O), connected to 30 groups of 2 actuators 
(from Ai to A 30 ), and a main processor (M), that communicates with / and O through a bus. 
At every cycle, the main processor polls results from the input processor that reads and pro¬ 
cesses data from the sensors. Based on these results, it elaborates commands to be passed to 
the output processor which controls the actuators. For instance, the input sensors can measure 
the fluid level, temperature, or pressure, while the commands sent to actuators could be used for 
controlling valves. 



Figure 5: A control system 

The reliability of the system is affected by the failures of the sensors, actuators, and processors. 
The probability of bus failure is negligible, hence we do not consider it. The sensors and actuators 
are used in 37 — of — 50 and 27 — of — 30 modular redundancies, respectively. Hence, if at least 
37 sensor groups are functional (a sensor group is functional if at least 2 of the 3 sensors are 
functional), the system obtains enough information to function properly. Otherwise, the main 
processor is reported to shut the system down. In the same way, the system requires at least 27 
functional actuator groups to function properly (a actuator group is functional if at least 1 of 
the 2 actuators is functional). Transient and permanent faults can occur in processors I or O 
and prevent the main processor(M) to read data from / or send commands to O. In that case, 
M skips the current cycle. If the number of continuously skipped cycles exceeds the limit K, the 
processor M shuts the system down. When a transient fault occurs in a processor, rebooting the 
processor repairs the fault. Lastly, if the main processor fails, the system is automatically shut 
down. The mean times to failure for the sensors, actuators, I/O processors, main processor, and 
the mean times for the delays are given in Table 1, in which 1 time unit is 30 seconds. A cycle 
lasts 2 time units, that is 1 minute. 

As described above, the system is modeled as a SHLPN. In the net, the places for each sensor 
group and each actuator group have 4 and 3 different markings, respectively. The places for I/O 
processors have 3 different marking, and the place for main processor have 2 different marking. 
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Therefore, the underlying CTMCs for the net has ~ 2^®® states comparing to the model in [17] 
with ~ states. 

6.2 Analysis Results 

The set of observed variables, the temporal resolution and their meaning are given in Table 1. We 
define four types of failures: f ailurei is the failure of the sensors, failure 2 is the failure of the 
actuators, failures is the failure of the I/O processors and failure 4 is the failure of the main 
processor. For example, failurei is defined as (number_sensors < 37) A (proci_status = 
2). It specifies that the number of working sensor groups has decreased below 37 and the 
input processor is functional, so that it can report the failure to the main processor. We define 
failure 2 , failures, and failure 4 in a similar way. In our analysis which is based on the one 
in [17] with TsT = 4, we used the Monte Carlo algorithm with 3000 simulations. 


Variable name 

Meaning 

Component 

Mean time 

number sensors 

number actuators 
proci status 
proco status 
proem status 

timeout counts 
reward up 
reward danger 
reward shutdown 

Working sensor groups 

Working actuator groups 

Input processor’s state 

Output processor’s state 

Main processor’s state 

Number of skipped cycles 

Time in “up” state 

Time in “danger” state 

Time in “shutdown” state 

Sensor 

Actuator 

Trainsient 

Processor 

Timercycle 

Reboot 

1 month 

2 months 

1 day 

1 year 

1 minute 
30 seconds 

Temporal resolution 

Meaning 



tick notified 

Observed variables are evaluated 

every one time unit 



Table 1: Observed variables and temporal resolution 

First, we study the probability that each of the four types of failure eventually occurs during 
the first T units of time using the formula F<t (failurei). Fig. 6 plots these probabilities for T 
varying from 5 to 30 days of operation. We observe that the probabilities that the sensors and 
I/O processors eventually fail are higher than the others. 


Sensor -♦-Actuator lO Processors Main Processor 



T (days) 


Figure 6: The probability that each of the 4 failure types in the first T time of operation 

For the second part of our analysis, we try to determine which kind of component is more likely 
to cause the failure of the system. In that frame, it is necessary to determine the probability that 
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a failure related to a given component occurs before any other failures. The atomic proposition 
shutdown, defined by Vi=i f ailurei indicates that the system has shut down because one of the 
failures has occurred. The formula ^shutdown U<t f ailurei is true if the failure i occurs within 
T time units and no other failures have occurred before the failure i occurs, that is if failure i 
is the cause of the shutdown. Fig. 7 shows the probability that each kind of failure occurs first 
over a period of 30 days of operation. It is obvious that the sensors are likelier to cause a system 
shutdown. At T = 20 days, it seems that we reached a stationary distribution indicating for 
each kind of component the probability that it is responsible for the failure of the system. 


Sensor -♦-Actuator -▼- IO Processors -A- Main Processor 



Figure 7: The probability that each of the 4 failure types is the cause of system shutdown in the 
first T time of operation 

For the third part of our analysis, we divide the states of system into three classes: “up”, where 
every component is functional, “danger”, where a failure has occurred but the system has not yet 
shut down (e.g., the I/O processors have just had a transient failure but they have rebooted in 
time), and “shutdown”, where the system has shut down [17]. We aim to compute the expected 
time spent in each class of states by the system over a period of T time units. To this end, we 
add in the model, for each class of state c, a variable reward_c that measures the time spent 
in the class c. The formula X<t reward_c returns the mean value of reward_c after T time 
units of execution over the 3000 traces considered. The results are plotted in Fig. 8. 

Finally, we approximate the number of input, output processor reboots which occur and the 
number sensor groups, actuator groups that are functional over time by computing the expected 
values of random variables that count the number of reboots, functional sensor and actuator 
groups. The results are plotted in Fig. 9 and Fig. 10. It is obvious that the number of reboots 
of both processors doubles the number of reboots of each processor since they have the same 
models. 


7 Related Work and Conclusion 

Some work has been carried out for dependability analysis with PMC, for example, the depend¬ 
ability analysis of control system with PRISM [17]. PRISM supports construction and analysis 
of Markov chains. For example, the exact probabilities in our case study can be computed by 
PRISM for the small system with one sensor group and one actuator group. However, the main 
drawback of this approach is that when it deals with real-world large size systems which make 
the PMC technique is unfeasible. That means the state explosion likely occurs, even with some 
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I Up ■ Danger ■ Down 


Expected time spent In each class of state (logT days) 


Figure 8: The expected amount of time spent in each of the states: “up”, “danger” and “shutdown” 


■ One Processor ■ Either Processor 



o 

O S 10 lb 20 2b 30 3b <10 4b bO 


Expected number of reboots 

Figure 9: Expected number of reboots that occur in the first T time of operation 

abstraction, i.e., symbolic model checking with Ordered Binary Decision Diagrams (OBDDs), is 
applied. 

Tabakov et al. [29] proposed a framework for monitoring temporal SystemC properties. This 
framework allows users express the verifying properties by fully exposing the semantics of the 
simulator as well as the user-code. They extend LTL by providing some extra primitives for 
stating the atomic propositions and let users define a much finer temporal resolution. Their 
implementation consists of a modified simulation kernel, and a tool to automatically generate the 
monitors and aspect advices for applying Aspect Oriented Programming (AOP) [6] to instrument 
SystemC programs automatically. 

This paper presents the first attempt to analyze the dependability of computer-based control 
systems using statistical model checking, in which the dependability of the systems is modeled by 
a SystemC-realization of stochastic high-level Petri nets. In comparison to the probabilistic model 
checking, our approach allows users to handle large industrial systems as well as to expose a rich 
set of user-code primitives by automatically instrumenting the SystemC code with AspectC 

Currently, we consider an external library as a “black box”, meaning that we do not consider 
the states of external libraries. Thus, arguments passed to a function in an external library 
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■ Actuator ■ Sensor 



O I I 

O 5 10 15 20 2S 30 35 40 4b 50 


Expected number of working actuators and sensors 

Figure 10: Expected number of functional sensor and actuator groups in the first T time of 
operation 

cannot be monitored. For future work, we would like to allow users to monitor the states of the 
external libraries with the future version of AspectC'*'’''. We also plan to apply statistical model 
checking to verify temporal properties of SystemC-AMS (Analog/Mixed-Signal) and make the 
improved version of the current naive inference algorithm implementation based on the RETE 
algorithm in [5]. 
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